Database administrators would like to monitor the status of the database systems they manage for various reasons. For example, administrators want to ensure that their respective database systems are constantly up and running and, if not, that any performance issues are handled promptly and swiftly so that users of the database systems are not adversely affected.
The users may be, for example, employees of a company. The database system may comprise proprietary information of the company. The employees require constant access to the proprietary information in order to perform their duties. Unresponsive or slow database systems in this context translate into lost money for the company.
As another example, the users may be online shoppers. The database system may comprise product information that the users may search via a web browser. Unresponsive or slow database systems in this context may cause some users to not purchase any items that they would have otherwise purchased. Worse still, some users may not return to the website because of the website's unresponsiveness. Less traffic to the website generally translates into lost revenue for the owner of the website.
Whatever the context, administrators of such database systems would prefer to be notified of any potential problems before the problems materialize and adversely affect user experience.
One approach that designers of database systems may implement so that administrators may monitor the status of their respective database systems is an eventing mechanism. An eventing mechanism included in a database system may allow an administrator to register for certain events. Examples of database events that may be of interest include, without limitation, updates to a certain table, the creation of an index, the size of a certain table after an update, the number of transactions within a certain time period, and the number of updates to a certain table within a certain time period. For each occurrence of an event for which a registration has been submitted, a separate notification is sent to the administrator that indicates that the event occurred.
However, one problem with such an approach is that a large number of events for which an administrator has registered may occur in the database system. As a result, the administrator may be overwhelmed with the resulting large number of event notifications that the administrator receives.
Based on the foregoing, there is a need to provide a mechanism for providing enough information to database administrators (or other users interested in events that occur in a computing system) so that they are notified of events without overwhelming the administrators with too many notifications.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.